The technology described herein relates to graphics processing and in particular to the operation of graphics processing systems that include one or more programmable processing stages (“shaders”).
As is known in the art, graphics processing is typically carried out in a pipelined fashion, with one or more pipeline stages operating on the data to generate the final render output, e.g. frame that is displayed. Many graphics processing pipelines now include one or more programmable processing stages, commonly referred to as “shaders”, which execute programs to perform graphics processing operations to generate the desired graphics data. For example, a graphics processing pipeline may include one or more of, and typically all of, a geometry shader, a vertex shader and a fragment (pixel) shader. These shaders are programmable processing stages that execute shader programs on input data values to generate a desired set of output data (e.g. appropriately transformed and lit vertex data in the case of a vertex shader) for processing by the rest of the graphics pipeline and/or for output. The shaders of the graphics processing pipeline may share programmable processing circuitry, or they may each be distinct programmable processing units.
As is known in the art, a shader program to be executed by a given “shader” of a graphics processing pipeline will be provided by the application that requires the graphics processing using a high-level shader programming language, such as GLSL, HLSL, OpenCL, etc. This shader program will consist of “expressions” indicating desired programming steps defined in the relevant language standards (specifications). The high-level shader program is then translated by a shader language compiler to binary code for the target graphics processing pipeline. This binary code will consist of “instructions” which are specified in the instruction set specification for the given target graphics processing pipeline. The compilation process for converting the shader language expressions to binary code instructions may take place via a number of intermediate representations of the program within the compiler, as is known in the art. Thus the program written in the high-level shader language may be translated into a compiler specific intermediate representation (and there may be several successive intermediate representations within the compiler), with the final intermediate representation being translated into the binary code instructions for the target graphics processing pipeline.
Thus, references to “expressions” herein, unless the context otherwise requires, refer to shader language constructions that are to be compiled to a target graphics processor binary code (i.e. are to be expressed in hardware micro-instructions). (As is known in the art, such shader language constructions may, depending on the shader language in question, be referred to as “expressions”, “statements”, etc. For convenience, the term “expressions” will be used herein, but this is intended to encompass all equivalent shader language constructions such as “statements” in GLSL.) “Instructions” correspondingly refer to the actual hardware instructions (code) that are emitted to perform an “expression”.
When a graphics processing output (e.g. a frame for display) is required, the graphics processing pipeline will be provided with a set of “commands” to generate the desired output. These “commands” are usually in the form of draw call descriptors which define respective draw calls to be executed by the graphics processing pipeline. These draw calls and their descriptors are generated in response to commands from an application running on a host system for graphics processing. A given draw call may use some or all of the graphics processing pipeline stages.
The Applicants believe that there remains scope for improvements to the operation of graphics processing pipelines that include one or more shader stages.
Like reference numerals are used for like components where appropriate in the drawings.